Modern businesses rely on a variety of applications and systems that control and generate information that is critical to business operations. Different applications often provide different services and information, and different users may require access to different levels of information within each system or application. The level of access that users are granted may depend on the role of the user. For example, a manager may need access to certain information about employees that report to him, but it may be improper for that manager to access the same information about those to whom he reports.
Earlier less sophisticated applications incorporated access management business logic directly into the application code. That is to say, each application would require users to have a separate account, separate policy logic, and separate permissions, for example. Furthermore, when a user is authenticated by one of these applications, this authentication remains unknown to other applications in the enterprise because the fact that authentication with the first application has taken place is not shared. Thus, there is no concept of trust between applications using different systems for authentication and access control. Engineers quickly realized that having an access management system for each application in an enterprise was much like having a gas station for each car, and determined that authentication and access control would be more efficiently implemented and managed as a shared resource. These shared resources became known as an access management systems.
Access management systems often use policies and other business logic to make a determination regarding whether a particular access request should be granted to a particular resource. Upon making a determination that access should be granted, a token is provided to the requestor. This token is like a key that can be used to open a door that guards restricted data. For example, a user may attempt to access a human resources database to gather information about certain employees such as salary information. The user's web browser makes a request to the application, which requires authentication. If the web browser does not have a token, the user is asked to log in to the access management system. When the user is authenticated, the user's browser receives a cookie that represents a token that may be used to access the human resources application.
An access management system may provide single sign on, authentication, authorization, and auditing features. Some releases of access management systems have a specific set of features that include authentication modules, authorization conditions, etc. These features are shipped with the access management system software “out of the box.” However, users of access management system software often desire features beyond those that are shipped with the access management system software. These users may desire customized authentication or authorization modules that are not shipped with the access management system software, for example.
Typically, while an access management system server is up and running, it is desirable to leave it up and running. Access management systems are supposed to be highly available. It is undesirable to take down the live access management system server for any reason. The undesirability of shutting down such a server even temporarily makes it inopportune to perform tasks, such as access management system software updates, that would typically require the server to be shut down at least temporarily.